home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 10179 < prev    next >
Encoding:
Text File  |  1996-08-05  |  3.1 KB  |  103 lines
  1. Newsgroups: comp.lang.c++
  2. Path: in1.uu.net!allegra!alice!bs
  3. From: bs@research.att.com (Bjarne Stroustrup <9758-26353> 0112760)
  4. Subject: Re: Inheritance vs Templates
  5. Message-ID: <Dnttq0.Lq6@research.att.com>
  6. Organization: Info. Sci. Div., AT&T Bell Laboratories, Murray Hill, NJ
  7. References: <4hf345$bnp@gwen.pcug.co.uk>
  8. Date: Wed, 6 Mar 1996 03:29:59 GMT
  9.  
  10.  
  11. Andy <williams@template.com> writes:
  12.  
  13.  > As a relative newcomer to C++(very relative) but an experienced
  14.  > OO programmer I'm having some problems seeing the place
  15.  > of Templates over the use of Polymorphism and inheritance.
  16.  > 
  17.  > It seems that templates do nothing extra (except efficiency ?)
  18.  > that could not be achieved using inheritance, and it seems that 
  19.  > inheritance is a more elegant approach?
  20.  > 
  21.  > Am I  completely missing the point? Any explanations would
  22.  > be warmly received.
  23.  
  24. Efficiency is one part of the answer (and that can be a big deal), and
  25. type safety is another. Consider containers.
  26.  
  27. Here is a simple list (for simplicity, I deal with pointers only here):
  28.  
  29.     template<class T> class list {
  30.     public:
  31.         T* get();     // remove and return current element
  32.         void put(T*); // put before current element
  33.         // ...
  34.     };
  35.  
  36. which can be used to write a function that rotates shapes:
  37.  
  38.     void f(list<shape*>* p)
  39.     {
  40.         while (shape* s = p->get()) s->draw();
  41.     }
  42.  
  43. Since the list is declared as a list of shapes, only shapes can be on it.
  44. This style of list in non-intrusive; that is, it doesn't require any
  45. restrictions on the layout of objects put on the list.
  46.  
  47. Consider another style:
  48.  
  49.     class List {
  50.     public:
  51.         Object* get();     // remove and return current element
  52.         void put(Object*); // put before current element
  53.         // ...
  54.     };
  55.  
  56. which can again be used to write a function that rotates shapes:
  57.  
  58.     void f2(List* p)
  59.     {
  60.         while (Object* oo = p->get()) {
  61.             if (shape* s = dynamic_cast<shape*>(oo))
  62.                 s->draw();
  63.             else {
  64.                 // oops! do something else
  65.             }
  66.         }
  67.     }
  68.  
  69. It is necessary to test whether the objects coming off the list really
  70. are shapes because objects of any class derived from class object can
  71. be put on the list.
  72.  
  73. To be on List, an object must be derived from Object. In particular,
  74. built-in types and types with layout constraints cannot be directly
  75. put on such lists (the way they can for the template-style list).
  76.  
  77. I consider the code using templates the cleaner by far. In C++, templates
  78. can be used to provide a type-safe interface for containers based on a
  79. "universal" base type. In other languages, syntactic sugar can hide the
  80. run-time check, but not the time and space overheads.
  81.  
  82. Both styles have been used in many successful systems; container class
  83. design is a multi-facetted and interesting topic. However, for a language
  84. such as C++, I think the template style is fundamentally cleaner.
  85.  
  86. The C++ standard library provides a variant of the template approach.
  87.  
  88.     - Bjarne
  89.  
  90. PS Note that the non-template style is actually a special case of the
  91. template case. Given the list template might define List like this:
  92.  
  93.     class List : public list<Object> { };
  94.  
  95.  > Please mail directly at
  96.  >      andy@template.win-uk.net
  97.  > 
  98.  > Many Thanks
  99.  > 
  100.  >                  Andy Williams
  101.  
  102.  
  103.